Calidad productiva

OVO applications are those that are integrated directly into OVO rather than by way of NNM. For these applications you can:

❏ Invoke them on the OVO management server and on all OVO managed nodes that are configured as OVO controlled nodes. ❏ Invoke them on several nodes in parallel.

❏ Change the list of target nodes, by selecting different nodes in the Managed Nodes window.

❏ Customize the start-up defaults. You can modify the following attributes:

• List of target nodes • Command parameters • User ID to use for execution • User’s password

❏ Allow the retrieval of the list of selected nodes using the reserved variable$OPC_NODES.

❏ Do not have or make use of OV Application Registration Files (ARFs) You can modify the configuration of an OVO application in the

Add/Modify OVO Application window. You can test the application immediately after configuration, and add parameters to the application that may or may not be altered by the operator.

The way an OVO application makes use of windows can be used to further classify OVO applications:

Table 3-2 Windows Used by OVO Applications

Type of OVO Window Examples Password Required

No Window X applications e.g.npuix,

xomniback, or when output is not of interest

No

Output Only Window ps(1),lpstat(1),df(1) No Input/Output Window sam,vi,more,npui,ftp,

nslookup

Integrating External Applications into the OVO GUI

For all three types of OVO application, you must define a user name. In addition, for applications that use an input/output window, the user’s password is required. The user name, used to run the application, can be different for the same application for each of the operators.

The following is a description of the user/password mechanisms used in OVO:

OVO application withNo Window option (e.g. X application): You need to define a user name but no password. When starting the application, OVO sends an RPC request to the action agent. The action agent, always running as root, switches to the appropriate user on the managed node, sets the DISPLAY variable, and starts the application.

This is mainly used for X-applications, however, you can also use it for terminal applications if a terminal emulator is available on the managed nodes. In this case, you need to specify this in the

application call, for example:

/usr/bin/X11/hpterm -e “ls -l /tmp”

OVO application withOutput only - Window option:

You need to define a user name but no password. When starting the application OVO opens a dialog box on the display and sends an RPC request to the action agent. The action agent locally switches to the appropriate user, executes the application, sends the output, using an RPC, back to the management server and displays it in the dialog box.

This is appropriate for the integration of applications which do not require interaction, for example, operating system commands like ps,bdf, and so on.

Integrating External Applications into the OVO GUI

You can avoid specifying a password if you define an .rhosts entry on the managed node with the specified user name. This method should only be used for terminal applications, and if no terminal emulator is available on the managed node. This is because:

• the need for specifying passwords or rhosts entries is difficult to maintain and, in most cases, is unlikely to meet the security policies of the customer, and

• there is an inherent lack of security in the rlogin mechanism, as it is possible to get shell access by sending a signal at the right time.

Integrating External Applications into the OVO GUI

Integrating HP OpenView Windows Applications

HP OpenView windows applications are applications already integrated into the HP OpenView platform. These applications are defined through OV application registration files (ARFs), and may then be integrated into OVO. Depending on the integration method, these applications are referred to as either OV Applications or OV Services.

Common characteristics of these applications are as follows: ❏ they are already integrated into HP OpenView windows

❏ their functions are defined in their Application Registration File (ARF), and not in the OVOAdd/Modify OV Applicationwindow or the OVOAdd/Modify OV Service window

❏ they are the only means of integrating map applications

❏ they are always started on the OVO management server, and rely on standard UNIX remote commands (e.g., remsh) to be started on systems other than the server

❏ they are restricted to startup on Customized OV Application Call Window and to the functionality defined by the window. (In particular, only objects passed to the OpenView application can be modified.)

❏ they allow the retrieval of the list of selected objects by using $OVwSelection,$OVwSelection1 and so on. The selection name of the object is passed to the OpenView application. Exceptions are the following objects, which may not be passed:

• OVO Message Groups

Integrating External Applications into the OVO GUI

HP OpenView Applications

HP OpenView applications integrated as OV Applications present the related application as an icon in the Application Desktop.

Double-clicking on the icon starts that action as described in the ARF. Note that OV Applications do not present the related menu items in the OVO submaps, even if the corresponding ARF contains menu items. Typical OV Applications are MIB Browser for SNMP, or HP OpenView OmniBack II.

Each action defined in the ARF must be integrated as a separate OV Application. This allows you to tailor and customize complex OV applications to the specific requirements of a user. You can specify a different bitmap/symbol for each action.

When the operator starts an application from the Application Desktop, the call is passed to the user’s ovw session, which always runs under the UNIX user ID of the operator who started the OVO GUI.

HP OpenView Services

For HP OpenView Services, the integration procedure is very similar to OV Applications but the operator does not see an icon on the Application Desktop. This means that the OV Service is either started automatically when the operator logs in to OVO, or it is started on demand from a menu or toolbar.

In the administrator’s Application Desktop, OV Services are represented by icons, however, unlike OV applications, they cannot be invoked by double-clicking. If required, you can invoke and access services from the menu bar. Although services cannot be invoked by clicking on an icon, they do appear as icons in the administrator’s Application Desktop, and may be distributed to operators by copying as usual.

An OV Service allows you to integrate OpenView applications which start daemons and/or should be integrated in the menu bar. This means that OVO operators have no graphical representation of their assigned services, but they might see or access additional submaps if the OV Service corresponds to an OpenView map application.

If menus are defined in the OV Application Registration File (ARF), these menu items will be integrated in the menubar of the OVO submaps for the operator.

Integrating External Applications into the OVO GUI

Integrating Applications into the Application Desktop

In document CAPÍTULO II MARCO TEÓRICO (página 33-38)