Application classes

A PATROL KM application class is any physical or logical system entity that it is possible to monitor. It can be a major component of an OS such as memory, or it can be a commercial software application such as a database. The application class is the basic building block of the object hierarchy. This section defines the concepts of application classes as they apply to PATROL KM development. A PATROL KM can define only one application class, but it may contain multiple instances of the application.

• Define the resource of interest for the PATROL KM, that is, the type of program, application, or OS object that the PATROL Agent is to recognize and monitor using the KM knowledge
• Set the properties that the monitored resource has in the PATROL interface
• Determine the methods that users use to interact with monitored resource in the PATROL Console interface
• Determine how the monitored resource appears in the PATROL Console interface
• Determine the types of events that the resource can trigger
• Create pseudo-containers to hold other application classes

How application classes work

The PATROL Agent loads the application class definition, and then parses and saves the application class information in the PATROL Agent namespace. Next, the PATROL Agent compiles and runs the application class pre-discovery script if it is defined. 

If the pre-discovery script does not detect the presence of the application, the discovery script is not compiled, and all application class information is purged. If the pre-discovery script successfully detects the application, the PATROL Agent compiles and runs the discovery script, which creates an application instances for each occurrence of the application. Usually in discovery, you need to create application instances. 

Once application instances are created, the PATROL Agent prepares and loads parameter executables, and they are queued for execution in their scheduled order. As parameter execution occurs, monitoring begins, and data for the parameters is populated as their values are returned.

Application instance states

A PATROL KM application instance can have five states. The following figure shows the standard state model for PATROL applications as they appear on the PATROL Console for Windows and UNIX. 
Parameter state models 

 

The following table describes the states of PATROL applications.

PATROL KM application state descriptions

For more information on PATROL icons see Requirements and guidelines for creating PATROL KM icons.

Considerations involved in defining PATROL application classes

Following are the considerations involved in defining PATROL application classes.

General PATROL naming guidelines

BMC Software recommends that you use a consistent naming scheme for all PATROL KM objects that you create. This avoids problems with duplicate object names and clearly identifies and associates your PATROL KM components. 

Follow these guidelines in naming PATROL objects:

• No spaces are allowed in names. This convention is enforced by the PATROL product.
• Make names meaningful.
• Us e a common KM prefix for the name of the KM and any file that you create as part of the KM. A KM prefix uniquely identifies the PATROL KM to which the application class belongs and associates all the parts of your PATROL KM. The KM prefix is a common practice in KM development. While PATROL does not care about your choice of prefix, it makes name collisions less likely to occur.
• Separate the KM prefix from the base application class name with a underscore (_) character.

Application class names

A PATROL application name is formed by adding a prefix to the root object name and separating the parts with an underscore () character. 

An application class name has the following format: 

_KMprefix_APPLICATIONCLASSNAME

• KMprefix identifies the PATROL KM to which the icon belongs; it is a 3-character (all upper case) code that designates a specific KM.
  Since PATROL stores all KMs in the same directory, it is very important that KMs and their associated files have a unique identifier.
• APPLICATIONCLASSNAME is made up of concatenated words (all upper case) that describe the application class.

For example, the FILES application class object on Windows for the MailBox KM whose KM code is MBX would be named MBX_FILES. 
The following table provides naming conventions for PATROL objects that facilitate code readability.

PATROL application naming conventions

Application class icons

You must designate graphic icons in an application class definition. These icons are used to represent application instances for display in the PATROL Console GUI. 
You must create two separate icon image files, an OK icon and an OK mask, for a single application class that displays in the PATROL Console for Windows. You must create four separate icon image files, an OK icon, an OK mask, a WARN icon and a WARN mask, for a single application class that displays in the PATROL Console for UNIX. The icons are used to indicate the different states that the application class can have.