HP OpenView System Administration Handbook [Electronic resources] : Network Node Manager, Customer Views, Service Information Portal, HP OpenView Operations نسخه متنی

7.1 Application Integration using Application Registration Files (ARFs)

The purpose of an ARF is to incorporate applications into the native NNM GUI. Many OpenView products extend the functionality of NNM by supplying ARFs. An ARF may be used to incorporate an application onto the menu bar, the symbol popup menu, or the toolbar. In fact, you may have noticed that many of the available applications in NNM can be accessed from more than one location. For example, you can view an object's properties by selecting

[Object Properties] from the symbol popup menu or by selecting the symbol and selecting

EditObject Properties… from the menu bar. The ARF not only defines how the application is executed but also where in the menu structure the application appears.

7.1.1 Creating Your Own ARF

Whenever you add an ARF to NNM, it must be placed in the directory structure $OV_REGISTRATION/C. A better practice would be to create a separate subdirectory for new ARFs under the subdirectory $OV_REGISTRATION/C. When started, NNM parses all files and directories located under this directory tree. If any file in this structure contains syntax errors, NNM provides a detailed error message ignoring files containing syntax errors and continues to start.

Tip

Because NNM parses every file in this directory structure, you should never create a backup copy of an existing ARF in this directory. If duplicate definitions are detected, NNM displays errors but continues to execute. Backup copies of your ARFs should be created in a directory other than the $OV_REGISTRATION/C directory structure.

Refer to Section 7.1.2, "Zman's Sample ARF," for the description in the following list. The name of the application ( "Database Information") indicates the beginning of the application definition in the ARF. Multiple applications may be contained in a single ARF. The ARF is broken down into the following blocks of code:

• Version
  Describes the NNM version for which this application was written.

• Description
  A brief description of the application.

• Copyright
  Copyright information.

• MenuBar
  If present, indicates the top-level menu for the application.

• Menu
  If present, indicates submenus and references to action blocks.

• Action
  Describes the device type, number of selected devices, and the command to execute the application.

• PopupItem
  If present, indicates the item on the symbol popup menu.

• ToolbarButton
  If present, indicates the toolbar icon for the application.

There are three basic functions that are used throughout the ARF:

f.separator
Indicates a menu item separator, which is a line between menu items.

f.action
Associates the call to the application or Action block.

f.menu
Indicates the name of the cascading menu.

In Figure 7-1, look at the area labeled 'MenuBar "Zman".' This defines the top-level menu bar from which the application is available. The name of the menu item is

"Database Information." The

_D defines the control key, in this case ctrl-D, that can be used to access the menu item instead of using the mouse. The Context describes the submap on which the application is available. "

AllContexts " indicates that the application is available on all submaps. The

f.menu is a keyword indicating a menu item named

"DB Info." The menu structure defined by the

MenuBar section is

ZmanDatabase InformationObject DB , as shown in Figure 7-1. For details on submap context refer to the Section 7.1.4, "Limiting Menu Items by Setting the Submap Context."

The next section,

Menu "DB Info," defines the actions that are executed when either of the two menu options (Object DB and Topology DB) is selected. The keyword

f.action references the Action blocks

ObjectDb_Info and

TopoDB_Info that define the command to be executed.

The Action block

Action "ObjectDB_Info" uses the selection rule to describe the type of devices on which this action can be executed. This action can be executed on a node that is SNMP supported, (isNode && isSNMPSupported). If the selected device does not meet the selection rule criteria, the menu item is not available. NNM uses menu graying to disable menu selections. For details on defining a selection rule, refer to Section 7.1.5, "Limiting Application Execution with the Selection Rule."

MinSelected and

MaxSelected allow you to define the number of items selected by the user to be available for the application. This example requires the user to select only one symbol to enable access to this application. Use of

MinSelected and

MaxSelected also causes menu graying.

The

NameField keyword indicates the object attribute that is passed to the command. In this case, the

IP hostname or the

IP address is passed through the variable $OVwSelections.

The

Command is the actual call to the application to be executed by the ARF. NNM provides the utility

xnmappmon to encapsulate the output of a text-based command into an X window, as shown in Figure 7-2.

xnmappmon provides a scrollbar for the output and works nicely with tools that provide text-based output, such as

ovobjprint . Execute

xnmappmon from the command line by typing

xnmappmon cmd ovobjprint  
selectionName 

The

Command in this example is a call to

xnmappmon, which calls

ovobjprint and passes the selected objects

$(OVwSelections) . OVwSelections is a run-time environment variable that consists of a list of selected objects that have been selected from the NNM GUI. Refer to Table 7-1 for a description of environment variables available for use in ARFs.

Zman's Sample

ARF uses two action blocks, one for the

ovobjprint command and one for the

ovtopodump command. The

ovobjprint command displays information extracted from the object database. The

ovtopodump displays information extracted from the topology database.

The PopupItem block indicates that the application is available on the symbol popup menu by right-clicking.

Zman's Sample

ARF adds two items to the popup menu:

Object DB Info and

Topology DB Info , as shown in Figure 7-3. The precedence value is optional and indicates where in the menu structure an item appears. The precedence value is a number ranging from 0 to 100. If no precedence is specified, the value is set to 50. If a menu bar item contains a precedence of 100, it appears as the left-most item on the menu bar. If two or more items have the same precedence, NNM orders the item alphabetically by the application name.

Context may be used to limit the submaps on which the item is available. You can specify the

TargetSymbolType to limit the availability (menu graying) of the application. The

TargetSymbolType may be specified as

ANY or

SymbolClass:SymbolSubclass in the ARF. For example, to limit an application to

HP-UX systems you would specify

TargetSymbolType Computer:HP-UX . View the symbol properties to find the class and subclass of an object. The keyword

f.action references the Action block of the application to be executed. The keyword

f.separator references a separator line that appears on the popup menu between the

Alarms and

Object DB Info items, as shown in Figure 7-3.

The

ToolBarButton indicates that a toolbar icon is available to execute this application. The syntax of the

ToolBarButton statement is similar to the

PopupItem . If a precedence is specified, it indicates where the toolbar icon appears, 0 being the right-most and 100 being the left-most toolbar icon. The @"toolbar/objectinfo.24.pm" indicates the location of pixmap for the toolbar button relative to $OV_BITMAPS. The toolbar icon in this example is located in $OV_BITMAPS/toolbar/objectinfo.24.pm. The sample ARF adds two toolbar icons, the "

O " for object information and the "

T " for topology information, shown in Figure 7-4.

Context is used to limit which submaps display the toolbar icon. The

f.action keyword references the Action block for the application.

7.1.2 Zman's Sample ARF

The following ARFs are available for download from the server http://www.phptr.com/title/0130352098 for both UNIX and Windows systems. Obtain the Readme file for Chapter 7 for a description of the files available and install procedures. You can parse a UNIX or Windows ARF to check for accurate syntax by executing the command

ovw verify .

Application "Database Information"
{
Version "OpenView NNM 6.01";
Description {
"ARF to print object.",
"Created by:",
"    Me",
}
Copyright {
"(c) Copyright 1997 Hewlett-Packard Co.",
"All rights reserved",
}
MenuBar "Zman"
{
"Database Information" _D Context "AllContexts"  f.menu "DB Info";
}
Menu "DB Info"
{
"Object DB"   _O CONTEXT "AllContexts" f.action "ObjectDB_Info";
"Topology DB" _T CONTEXT "AllContexts" f.action "TopoDB_Info";
}
Action "ObjectDB_Info"
{
SelectionRule (isNode && isSNMPSupported);
MinSelected 1;
MaxSelected 1;
NameField "IP Hostname", "IP Address";
Command "xnmappmon -commandTitle \"Object Database Information\"
 -commandHeading \"Output from ovobjprint:
 \" -cmd ovobjprint -s ${OVwSelections}";
}
Action "TopoDB_Info"
{
SelectionRule (isNode && isSNMPSupported);
MinSelected 1;
MaxSelected 1;
Command "xnmappmon -commandTitle \"Topology
 Database Information\" -commandHeading \"Output from ovtopodump:
 \" -cmd ovtopodump -l ${OVwSelections}";
}
/********************************************************/
PopupItem <90> "PopupSeparator5" Context (AllContexts ||
 WantPopupMenus) TargetSymbolType

 ANY f.separator;PopupItem "Object DB Info" CONTEXT "
AllContexts"
TargetSymbolType ANY f.action "ObjectDB_Info";
PopupItem "Topology DB Info" CONTEXT "AllContexts"
TargetSymbolType ANY f.action "TopoDB_Info";
/********************************************************/
ToolbarButton <80> "TBAR_SEP5"  Context "AllContexts" f.separator;
ToolbarButton <80> @"toolbar/objectinfo.24.pm"
Context "AllContexts" f.action "ObjectDB_Info";
ToolbarButton <80> @"toolbar/topoinfo.24.pm"
Context "AllContexts" f.action "TopoDB_Info";
/********************************************************/
}

7.1.3 Zman's Extra Cool Object Info ARF

The second ARF sample provides the popup menu item

Show Zmans Xtra Cool Object Info , shown in Figure 7-3. This example consists of two files: an ARF and an executable script

showzmansxcoi (

SHOW ZMANS E

X tra

C ool

O bject

I nfo). The action block defined in the ARF calls the script

showzmansxcoi . The script calls

xnmappmon to encapsulate the output of

ovtopodump , as shown in Figure 7-5.

7.1.3.1 The Code For Zman's XCOI ARF

This ARF should be placed in a subdirectory under $OV_REGISTRATION/C. It will be parsed when you start ovw.

Application "Show Zmans Xtra Cool Object Info"
{
Description {
"HP OpenView Windows application"
}
Version "NNMGR 7.0";
Copyright {
"(c)Copyright 1992-1995 Hewlett-Packard Co."
}
/*
*  OVw Popup menu
*/
/*===========================================================*/
PopupItem <100> "PopupSeparator2" Context
 (AllContexts || WantPopupMenus)
TargetSymbolType ANY f.separator;
PopupItem <100> "Zmans Extra Cool Object Info" Context 
(AllContexts || WantPopupMenus)
TargetSymbolType ANY f.action "Zmans_XCOI_4popup";
/*===========================================================*/
/*===========================================================*/
Action "Zmans_XCOI_4popup"
{
Command "${showzmansxcoi:-/opt/OV/bin/showzmansxcoi} ";
}
/*===========================================================*/
}

7.1.3.2 The showzmansxcoi Script

This script should be placed in the directory /opt/OV/bin or the directory referenced by the Command statement in the "Show Zmans Xtra Cool Object Info" ARF. The script needs to have executable permissions.

#!/usr/bin/sh
#
# Zmans show extra information for incorporation into
# the symbol popup
#
#
#
THECMD="ovtopodump -l $OVwSelection1"
THERESULT=`ovtopodump -l $OVwSelection1 2>&1`
THEERROR=`echo $THERESULT | cut -f1 -d" "`
if [ "$THEERROR" = "ERROR:" ]
then
THECMD="ovobjprint -s $OVwSelection1"
fi
xnmappmon -commandTitle "Zmans Extra Cool Object Information"
-commandHeading "Information on ${OVwSelection1}" cmd
${THECMD}
exit 1

7.1.4 Limiting Menu Items by Setting the Submap Context

Submap contexts may be used to limit the occurrence of an application to a specific submap. When you specify a submap context other than AllContexts, the application is not available on submaps that do not meet the context criteria. You can define a custom submap context for an application by navigating to the submap you would like to customize and selecting

Map)SubmapProperties from the menu bar. Click the

[Submap Context…] button and add a unique context such as

isMySubmap to the context list. To use this submap context in an ARF, you would include

Context "isMySubmap" in the ARF.

7.1.5 Limiting Application Execution with the Selection Rule

The selection rule can be used to limit devices on which an application may be executed. When specifying a selection rule, the menu item for the application is grayed out unless the selection rule criterion is met. For example, the selection rule

isNode && isSNMPSupported indicates that the device must be an SNMP-supported node. A selected device must meet the criteria specified by the selection rule in order to execute the application. NNM plugin applications such as CiscoWorks^® use elaborate selection rules so that menu items can only be executed on certain Cisco devices.

One way to obtain object attributes for the selection rule is to view the object properties of a device from the GUI. Right-click the device, select

Object Properties , and view the

Capabilities or

General Attributes . Any attributes from either list may be used when defining the selection rule.

Object attributes may also be obtained with the command-line utility

ovobjprint . The Selection Name of an object must be used with the ovobjprint command. The following example command lists the object attributes for the system r208w100:

ovobjprint s r208w100 

The output of

obobjprint is similar to the output shown in Section 7.1.6.

7.1.6 Output of ovobjprint

OBJECT: 5519
FIELD ID FIELD  NAME                     FIELD VALUE
10              Selection Name           "r208w100"
11              IP Hostname              "r208w100"
14              OVW Maps Exists          4
15              OVW Maps Managed         4
17              vendor                   Hewlett-Packard(1)
27              isNode                   TRUE
29              isComputer               TRUE
30              isConnector              TRUE
31              isBridge                 FALSE
32              isRouter                 TRUE
33              isHub                    FALSE
37              isWorkstation            TRUE
52              isIP                     TRUE
53              isIPX                    FALSE
517             IP Status                Normal(2)
521             isIPRouter               TRUE
522             isIPXRouter              FALSE
523             isNetWareServer          FALSE
559             isSNMPSupported          TRUE
561             SNMP sysName             "r208w100"
562             SNMP sysDescr  "HP-UX r208w100 B.11.00 U 9000/800 2007773835"
565             SNMP sysObjectID         ".1.3.6.1.4.1.11. 2.3.2.3"
566             SNMPAgent                HP 9000/HP-UX(4)
578             TopM Interface Count     4
TopM Interface List
"lan0       Normal     156.32.122.21    257.257.248.0   <None> 0x001083F5D972 

 ethernetCsmacd      "156.32.122.153 Normal 157.32.122.153   257.257.248.0   <None> 

 0x001083F5D993  ethernet Csmacd      "lan2    Normal  152.20.4.15     257.257.257.0

   <None>        0x080009B8E98B  ethernetCsmacd      "lan1    Normal     <None>         

 <Unknown>     
  <None>        0x001083F5D928  ethernetCsmacd      "
586          isMcClusterMember           TRUE
587          isCollectionStationNode     FALSE
1514        isOPCmanaged                 TRUE
1515       OPC_ID               "N:M315eb856-4910-71d4-1c51-0f207a980000"
1533        isOPCnode                    TRUE
8053        isMCClusterObj               TRUE
8062        MCSGClusterID                961088970
8063        MCSGClusterObj               Status  1
8067        isMCSGClusterNode            TRUE
8068        MCSGNodeID                   2

The operators in Table 7-2 may be used when defining a selection rule. Any of the object attributes listed by the

ovobjprint command may be used when defining the selection rule. Most of the examples listed in Table 7-2 are self explanatory, with the exception of

"TopM Interface Count." "TopM Interface Count" indicates the number of interfaces listed in the topology database for the device.

"TopM Interface Count" may be used to create an ARF that only executes on devices containing multiple interfaces by adding this statement to the ARF:

SelectionRule ("TopM Interface Count" > 1)

7.1.7 Use Your ARF as an Executable Symbol

After you've created an ARF, the application defined by it becomes a registered application in NNM. The application can now be used when creating executable symbols. Add an object to a submap, change the behavior to executable, and check the list for your application. Refer to Chapter 4, "Out-of-the-box Network Node Manager," for details on creating executable symbols.

7.1.8 The ovw Application Registration File

The file

$OV_REGISTRATION/C/ovw defines the entire menu structure, toolbar, and symbol popup items of the NNM GUI. You can limit user access to applications by modifying this file. As with any ARF, never make a backup of this file in the

$OV_REGRISTRATION/C directory or it will cause duplicate error messages. In the event that you destroy the ovw file beyond repair, an original copy may be found in the

$OV_NEW_CONF/OVWIN/registration/C directory.

7.1.9 Limiting Access to Applications using OVwRegDir

The

$OVwRegDir environment variable can be set to define ARF directories for individual users. This is helpful when limiting access to applications. For example, a user might need access to applications that work only with networking devices. These applications might not need to be available to everyone. The ARFs can be located in any directory. For example, if custom ARFs are located in /etc/opt/OV/customRegDir on a Unix system, you would define the environment variable in a user's

.profile as follows:

export OVwRegDir=/opt/OV/share/registration/C:/etc/opt/OV/ 
customRegDir 

By defining this environment variable, you have limited the access to the ARFs located in /etc/opt/OV/customRegDir to users who export the

OVwRegDir as specified. Registration directories are separated by a colon (:).

For Windows systems, you could add the custom ARF directory to the user's system variable list or modify and execute the

ov.envvars.bat file.