Importing macro-events

This topic contains the following sections:

Importing new events

 The process consists of the following steps:

  1. Develop or configure an ETL that populates the dataset EVDAT by navigating to the Administration> ETL & SYSTEM TASKS > Add > Add ETL section of the Helix Capacity Optimization Console.
  2. Run the ETL.
  3. Configure the Event Manager to manage the new events.
  4. Run the Event Manager and check its results.

For steps 1 and 2, refer to Maintaining ETL tasks. For steps 3 and 4, refer to Managing events and associating them to metrics.

Event lifecycle

The lifecycle of a BMC Helix Capacity Optimization event is represented by the following key statuses:

  • PENDING: The event is created and awaiting to be processed.
  • INTERVENT: The first intervention on this event (for example, an incident that needs to be solved).
  • RESOLUTION: The event is resolved (that is, closed).

This is a generic status set, whose purpose is not to describe in detail the transitions of the event, but only to identify significant transitions for event analysis and reporting.

According to these transitions, the following measured times are defined:

  • Event pending time: Total time in pending status, even if the pending status has been reached more than one time.
  • Event resolution time: Total time elapsed from start to resolution.
  • Event intervent time: Total time elapsed from start to first intervention.

Event tracing

An ETL can load events that are traced in different ways:

  • STATELESS: The event has not traversed the expected workflow (for example, pending-intervent-resolution). The only meaningful time stamp for this event is "instantaneous", and it is called EVENTS. Transition times (pending, resolution, intervent) are meaningless. Usually, this represents a planned maintenance or similar situation.
  • STATE SUMMARY: The event has traversed the expected workflow (for example, pending-intervent-resolution) and was imported when closed. In this case, all defined times (pending, resolution, intervent) are calculated by the ETL and imported. EVENTS, INTERVENTTS, and RESOLUTIONS are used to represent all status timestamps. transitions.
  • STATE TRANSITION: The event is traversing the expected workflow (for example, pending-intervent-resolution) but is still being processed. In this case, the STTRTS column indicates the status transition timestamp of the transition that a record is reporting, and the STTRSTA indicates the new status (PENDING,INTERVENT,RESOLVED). Based on transition records, the event is processed by BMC Helix Capacity Optimization calculating meaningful transition times.

The event tracing type is automatically detected based on the following policies:

  • The event is STATELESS if the row has only EVENTS.
  • The event is STATESUMMARY if the row has both EVENTS and RESOLUTIONS.
  • The event is STATETRANSITION if the row has STTRTS, STTRSTA and status specific time stamps.

The following figure shows STATETRANSITION events status changes and the dataset columns to populate in order to enable status transitions:

Event Tracking Overview

Event lookup

The ETL must ensure different lookups:

  • The lookup of the event itself, for which the DS_EVENTID column is used, which is important to avoid duplicates and to recognize the transitions of a specific event in STATETRANSITION mode.
  • The lookup of a system, workload or time series with which the event must be associated (optional).

In particular, the second lookup type is important if the event is an incident that must be associated with the affected system. In this case, the ETL that imports the event is usually not responsible for creating or importing data about the system itself. However, the event will be automatically associated with the correct system, as that the ETL populates the column DS_SYSNM in the dataset using the correct lookup name of the system.

An Event Manager rule can be used to enable automatic association even if the lookup between the two data sources (events and monitoring) is slightly different.

The EVDAT dataset

Column name




Event timestamp

Timestamp of the event or transition (YYYY-MM-DD HH:MI:SS).


Event intervention timestamp

Intervention timestamp of the event (YYYY-MM-DD HH:MI:SS).


Event resolution timestamp

Resolution timestamp of the event (YYYY-MM-DD HH:MI:SS).


Event pending timestamp

Pending timestamp of the event (YYYY-MM-DD HH:MI:SS).


Event identifier in the data source

Event unique identifier in the data source.


System name in the data source

The name of the system with which the event is associated, as in the data source.


Workload name in the data source

The name of the workload with which the event is associated, as in the data source.


Location name in the data source

The name of the location with which the event is associated, as in the data source.


Resource name in the data source

The name of the resource with which the event is associated, as in the data source.


Sub-resource name in the data source

The name of the sub-resource with which the event is associated, as in the data source.


Event type

Type of the event (see CKB:note)








Count of occurrencies

Count of occurrences





Event intervention time

Event intervention time, in seconds


Event pending time

Event pending time, in seconds


Event resolution time

Event resolution time, in seconds





Event class as classified in the data source

A classification label used in the data source to classify the event; can be more detailed compared to the event type.


Service unavailability

A measurement of the service unavailability caused by this event; for example, 100% means that the incident has caused a total unavailability.


State transition status

State transition status


State transition timestamp

State transition time of the event (YYYY-MM-DD HH:MI:SS)


Tracing type

Automatic column, generated interpreting other columns according to tracing policies explained above.


EVENTTYPEID must be one of the available event types:

  • 1 = Unplanned incident
  • 2 = Planned generic
  • 3 = Planned maintenance
  • 4 = Planned change
  • 5 = Unplanned problem
  • 6 = Unplanned error
  • 7 = Unknown

See Also

For a general introduction to macro-events and what they are used for in BMC Helix Capacity Optimization, see Events.

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