This documentation supports an earlier version of BMC Helix Operations Management.

To view the documentation for the latest version, select 23.1 from the Product version picker.

Event classification and formatting

Data collected from various sources are classified based on event classes and then formatted and represented as events. An event is a specific instance of an event class. 

Raw events contain information such as source, location, time stamp, and other important information about the event. This information is represented by event slots (name=value pairs). Every event class has a set of associated slots that can be used for processing events.

How are raw events ingested?

BMC Helix Operations Management  accepts and processes an incoming event if it matches the predefined event class definition. When an event is collected, the product compares the incoming event to the class definitions to determine the event type and to validate the event. In the event processing stage, as part of the event classification:

  • Raw events with mandatory slot information are accepted. Events are deduplicated based on the out-of-the-box dedup slots. Topology is established between events in BMC Helix Operations Management  and service models in BMC Helix AIOps  based on the topology facets, and other factors. All this processing occurs based on slot facets.   
  • Raw event data is stored in the form of name=value pairs with the appropriate data types based on the slot data types

The following image illustrates at a high-level how an event is ingested:

If an incoming event does not match the class definition,  BMC Helix Operations Management  performs these actions:

If an incoming eventThen

Is of an unknown or undefined class

  • The event is ingested and continues to processing.
  • The event class is set to the base Event class.
  • The _errors slot is updated with the details.

Does not contain values for mandatory custom slots

  • The event is ingested and continues to processing.
  • The _errors slot is updated with the details.
  • The mandatory custom slots are added with blank values.

Matches a predefined class, but contains unknown or undefined slots

  • The event is ingested and continues to processing.
  • The undefined slot names and their corresponding values are stored in the _unmapped_data slot.

Matches a predefined class and slot names, but the slot data type is incorrect

Example: Alphabetical string data in an integer slot

  • The event is ingested and continues to processing.
  • The default slot values are used, if any.
  • The incorrect values and their corresponding slot names are stored in _unmapped_data slot.

After an event is ingested, you can update the missing or incorrect details by running the API endpoint for updating an event.

How are events classified?

Event classes can be defined based on the event origin and usage. An event class can be subdivided into several subclasses to classify event information at a more detailed level. 

For example, one class of event might be Microsoft Windows operating system events. That event class can have several subclasses: application events, security events, and system events. Each subclass represents a common type of event that occurs, such as a network logon, that contains varying data values, such as a time stamp and the name of the host on which the logon occurred. The varying data values from a source event are stored in data fields called slots. 

The following image illustrates the hierarchy of the event classes described in the example:

Events flow through phases based on certain built-in rules. These rules specify which events are selected for processing and then determine how they are processed. The capability of dividing event classes at a detailed level allows the product to apply these built-in rules at a granular level and process the events. 

Events can also be processed after they are ingested by using event policies. To understand the order in which policies are evaluated and processed, see Event policy types and evaluation order.  

What are the types of event classes?

Event classes can be categorized into:

  • Out-of-the-box classes: These event classes are available by default with  BMC Helix Operations Management :
  • Custom classes: These classes can be defined to create new classifications of events in  BMC Helix Operations Management .
    For more information about creating custom classes and custom slots, see Managing events with REST APIs.

  • Classes for BMC Helix Developer Tools  connectors: These classes are used for ingesting events coming from third-party products such as Dynatrace, SolarWinds, and so on. When you add an integration using one of the BMC Helix Developer Tools  connectors, event data collected from those connectors is made available in  BMC Helix Operations Management . However, note that events coming from TrueSight Operations Management  are generated as Alarm events.
    For information about BMC Helix Developer Tools , see Integrating by using BMC Helix Developer Tools Open link .
  • Classes for BMC Helix Intelligent Integrations  connectors: The IIMonitorEvent class and its subclasses are used for ingesting events coming from third-party products such as Aternity, AppDynamics, and so on. When you add an integration using one of the BMC Helix Intelligent Integrations connectors, event data collected from those connectors are made available in BMC Helix Operations Management
    For information about BMC Helix Intelligent Integrations , see Integrating by using BMC Helix Intelligent Integrations Open link .

How does event class inheritance work?

The out-of-the-box event class definitions are organized in a multilevel hierarchical system where a superclass (or parent class) can be assigned subclasses (or child classes). Subclasses automatically derive definitions from the superclass. This behavior is called inheritance.

The following image represents the multilevel hierarchical system: 

The base Event class is an out-of-the-box superclass. Therefore, the base Event class definitions are inherited by all the other out-of-the-box subclasses. The MonitorEvent class available under the base Event class contains a set of common purpose slots that can be used across all the subclasses. 

Best practice

You can add common purpose slots under any event class (except the read-only base Event class) and have the child classes inherit those slots. Although adding common slots under any class is possible, we recommend that you use the MonitorEvent class for adding common purpose slots.

A subclass inherits all the slot definitions of the superclass. A subclass can also contain additional new slot definitions (or custom slots) of its own and slot definitions that override a superclass slot definition. However, when a subclass slot overrides a superclass slot definition, it cannot have a data type that is different from the inherited slot, only different slot values. Custom classes can be defined under the base Event class and under the MonitorEvent class. Custom classes can have multiple subclasses. 


  • Custom slots can be added under all the out-of-the-box classes except the base Event class. 
  • Out-of-the-box slots and custom slots cannot be deleted. You can only add new slots and update existing slots under custom classes.
  • The out-of-the-box event classes can be updated but not deleted. However, the base Event class can neither be updated nor deleted. It is a read-only class.

  • Creating event class slots with the same name but different data types across multiple custom classes are not supported.
    For example, if the application slot is defined as a String in MyCustomClass, then it cannot be defined as an Integer in MyOtherClass.

This multilevel hierarchical structure of classes provides the following advantages:

  • Eliminates the need to create multiple blackout and event policies for each class separately. 
  • Allows you to define multiple custom classes. Custom classes can be defined under any class, including other custom classes. 
  • Allows you to define common custom slots that can be inherited across all the subclasses.  

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