2.1 High-Level Data Model
This section describes some of the core entities exposed in the WSAPI. Understanding how these entities relate to each other and to the entities exposed in the client user interface (UI) is necessary to effectively use the WSAPI.
Figure 2-1 shows the high-level relationships among the following WSAPI entities:
-
MosElement
-
MosAlarm
-
MosSeriesDescriptor, DataPoint
-
MosSla, HealthData
Figure 2-1 High-Level WSAPI Entity Relationships
The following sections provide further explanation:
2.1.1 Elements and their Relationships
A MosElement is the WSAPI representation of an element in the Operations Center Server. Elements are the core structural entity in the Operations Center Server. An element can represent any of the following:
-
A physical system or a service in the customer environment
-
A service internal to the Operations Center Server
-
Logical groupings of services and/or systems
In the Explorer pane of the Operations Center console, each node in the tree structure is an element.
Figure 2-2 MosElement Identity Fields
The fields in Table 2-1 identify a MosElement.
Table 2-1 MosElement Identity Field Descriptions
|
Field |
Description |
|---|---|
|
DName (string) |
Elements are identified by a distinguished name (DName) field composed of the name and class of the element and all of its parents in the tree hierarchy. Moving or renaming an element changes the element’s DName as well as the DNames of its children. |
|
tempId (long) |
A unique numeric identifier assigned to an element by the Operations Center Server during server startup or during element creation, if the element is created after server initialization. Unlike the DName, the tempId does not change when elements are moved or renamed. Use the serverStartTime field of MosServerInfo to determine if a tempId value is still valid. |
The element tree structure in the Operations Center console can reflect both physical and logical associations among the displayed elements. A physical association is a name relationship as reflected in the element DNames. Each nonroot element has exactly one parent and can have zero to many children.
Logical associations are created to provide various views of element data. An example of a logical relationship is the ability to configure elements as links that contribute to the state of a service model. Although these elements are not physical children of the service model, they can display under the service model in the tree hierarchy.
When relationship information is included in a MosElement, it is represented as either a “left” or “right” RelationshipInfo object embedded in a MosElement. In most cases, “right” relationships can be viewed as associating child or source elements and “left” relationships as associating parent or destination elements:
Figure 2-3 MosElement Relationship Information
2.1.2 Alarms
A MosAlarm is the WSAPI representation of an alarm in the Operations Center Server. Alarms represent recorded events that are captured by an adapter (such as a T/EC event) or by an internal configuration (such as an SLA breach). Although each alarm is tied to a single element (sometimes called the home element), elements can be configured to share the alarms of associated elements. Alarms can be current or historical.
Table 2-2 shows MosAlarm fields.
Table 2-2 MosAlarm Identity Fields
|
Field |
Description |
|---|---|
|
elementDName (string) |
The DName of the element to which the alarm is attached; the alarm’s home element. The other IDs in the alarm should be scoped to the home element. |
|
id (long) |
Similar to MosElement.tempId, this value is assigned when the alarm is created and remains constant for the life of the alarm. This value might not survive a server restart. |
|
persistentId (string) |
Use this ID for alarms that are persistent across a server restart. |
The element DName ties MosAlarm to the element to which the alarm is attached as shown in Figure 2-4.
Figure 2-4 The DName Element Field for the MosAlarm Element
2.1.3 Series Data
Series data refers to element data that is tracked over time. In the Operations Center console, series data is usually displayed as charts in the Performance view for the element.
The WSAPI exposes series data by using several types of DataPoint objects, each representing a single value at a specified point in time, and a MosSeriesDescriptor object to describe a series of related DataPoints.
A MosSeriesDescriptor is scoped to a single MosElement and is distinguished within an element with the combination of the profileName and expressionName fields. DataPoints within a series are distinguished by time stamp:
Figure 2-5 A MosSeriesDescriptor Object
2.1.4 SLA Data
A MosSla is the WSAPI representation of a Service Level Agreement (SLA) in the Operations Center server. An SLA is a collection of objectives (MosObjective) and other configuration data that are used to evaluate the performance of elements. Each SLA is associated with a specific element and is distinguished within that element by the SLA name. An SLA can be shared with child or source elements in much the same way that alarms can be shared with parent or destination elements. The performance of an SLA over time is exposed as a set of HealthData objects.
HealthData objects are similar to series data DataPoint objects, except that they represent a period of time instead of an instance and they are calculated dynamically based on specified request criteria:
Figure 2-6 A MosSla Element
