Service components

This section contains overview information about components classes and types, types of service CIs, and component statuses.

Component classes and types

A class is the definition or metadata that describes an object type. The class includes information about the object type, such as attributes, primary key, and so on. You can view a list of subclasses or child classes that are associated with a class.

A service component class is a CDM class that is available for inclusion in a service model. These are the only classes visible in BMC Impact Model Designer. Some classes of objects are not visible because they do not make sense in a service model (for example, BMC_Keyboard).

A service component type is a data class that defines a logical or physical asset that participates in the delivery of a business service. Service components can represent a hardware component, an application, a service, customer groups, or any aspect of business for which you want to employ service impact management.

Service components are organized in a hierarchy of classes in which each class represents a component type. The farther down the hierarchy a particular class occurs, the more specific its type.

When you define a new service model component, you must create it by using a subclass of the BMC_BaseElement class. Select the most appropriate subclass for each component that you want to create. If an appropriate subclass does not exist or is too generic, you can extend the class hierarchy by adding a new subclass definition to the BMC Atrium CMDB Class Manager. You can also extend an existing class definition by adding one or more slots to store component-specific information.

Classes and their creation are covered in detail in Modifying your data model.

Service configuration items

A configuration item is a specific, unique occurrence of a component type. A component type is the generic object: for example, server. The CI is the specific, unique version of the type: for example, JBossServer 123. You can select one of the component types from the Templates dockable window and modify that template to create a CI that defines a specific logical or physical asset.

All service model classes and related slots are stored in the <installationdirectory>/pw/server/etc/default/SIM/kb/classes/mc_sm_object.baroc file. For a description of data class definitions that support the service model, see Designing a service model

Component status and substatus

A service CI is characterized by its status, which is indicated by the color of the component's icon in the Operations Console of Infrastructure Management.

Information about the status of a CI is stored in the cell in the instance's status slot. The initial status of a service CI, just after its creation, is determined by the default value of its class-level status slot. (Usually this value is green or OK .)

Component status computation

The status of a CI is computed automatically by the cell when new conditions occur, as follows:

  • A new event  that has a direct impact on the component is received.
  • The severity of an event impacting a component changes.
  • Another component's status change is propagated to the component.

Whether the status of a component is influenced directly by events, by other components' status changes, or both, depends on the component's type and its relative position in a particular service infrastructure. For example, the status of an IT component usually reflects the associated resource events that directly impact its status. In contrast, logical components such as applications or business groups rely on their relationships to IT components to provide their current status.

The cell computes a component's status by using a status computation model that you assign to the CI in the StatusModel attribute. Based on the specific status computation model, the cell uses an algorithm to calculate the following values:

  • Status values propagated by inbound relationships
  • Severities of direct events associated with the service CI
  • Impact status and service component self-status

The predefined status computation models available are Standard, Cluster, Weighted Cluster, and Self-Preferred.

The Weighted Cluster status computation model uses the Status Weight attribute of the impact relationship object. Status Weight is used in impact relationships to determine how much importance (numerically weighted) to give to each provider relationship that impacts a consumer instance. The higher the number, the greater the importance.

You can select the status computation model for each CI in the Edit Component Properties dialog box, on the Status and Alias tab, in the Status Computation list. BMC Impact Model Designer ensures that each CI is associated with a valid status computation model. For information about the Edit Component Properties dialog box, see To specify attributes for configuration items

For more information about component status computation and status computation models, see Designing a service model.

Note

Whether and how the status of a provider component is propagated through a relationship is controlled by the relationship policy assigned to the CI.

Was this page helpful? Yes No Submitting... Thank you

Comments