IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing monitor models > Create monitor models > Defining monitor details models
Defining monitoring contexts
A root-level monitoring context is automatically defined whenever you create a monitor details model. It must be completed with definitions of its elements, such as metrics, triggers, and event subscriptions.
To create a new monitoring context, click the Monitor Details Model tab, right-click the monitor details model at the top of the model tree, and click New > Monitoring Context. Or, to create a nested monitoring context, right-click a monitoring context and click New > Monitoring Context.
To define a monitoring context:
Procedure
- Click the Monitor Details Model tab of the editor and click the monitoring context.
- To change the ID, click Edit on the ID field. The ID is required, and it must be unique for all monitor models. The ID must be an XML NCName (non-colonized name), which means that it must start with a letter or underscore and that it can contain only letters, digits, underscores, hyphens, and periods.
The monitoring context ID must be unique within the monitor model. Other elements are required to be unique only within their own containers; for example, an inbound event ID must be unique within its own monitoring context or KPI context.
- Optional: Type a new name in the Name field.
- Optional: Type a description in the Description field. The description is used only in the Monitor Model editor and is not displayed anywhere in Business Monitor. The character set is unrestricted.
- To specify that this monitoring context not be shown on the dashboard, select Hide from dashboards.
- Optional: Specify quality of service properties to provide the location of configuration information inside your events rather than relying on the standard Common Base Event fields. When you specify one of these properties at the monitoring context level, the value is applied to all descendant inbound events, except those that are contained in a descendant context that specifies the same property. You can override the value for individual inbound events by providing a custom value on the inbound event page.
Content assist is not available to help you select the event attributes to use for the paths, because the inbound events will have different structural characteristics and there is no single event definition that can be used as the basis for content assist. You can define an expression that refers to any constant, function, or event attribute.
- Specify an event sequence path, which is a path to an event attribute that indicates the processing order for inbound events. The event sequence expression must start with the ID of the inbound event. If no event sequence path is defined, events are processed in the order in which they arrive. For more information about event sequence paths, see Event sequence paths.
- Specify the path to the creation time of the event. The Monitor server uses this attribute to indicate the instance creation time, for example, to determine the stop and start times of a stopwatch, or to determine which instances should be included when calculating historical KPI values. By default, the value used at run time is the path to the Common Base Event creationTime attribute, which contains the time at which the event is created, in UTC. Alternatively, you might want to use a more business-relevant creation time from the event payload, such as the date and time that an order was placed.
- Specify the path to the global instance ID. This ID is used to relate the problem determination message to a specific event when there is an error at run time, (for example, in the WebSphere Application Server log). By default, the value used at run time is the path to the Common Base Event globalInstanceId, which is an automatically generated identifier to uniquely identify the event.
- If this monitoring context was generated from a Process Server application, an Application element field shows the display name of the event source that is linked to this monitoring context.
If any of the elements in the monitoring context were generated from templates, the templates are shown in the table. Open a template to see the managed elements.
For example, if you open a Start Time template, you see a Start Time metric and inbound events for each event that can create a monitoring context. If more than one event source is associated with this monitoring context, you can select an application element from the list to see the associated templates and elements.
To remove the association between the monitoring context and the application, click Remove.
Important: Removing the association also removes all associations to application elements from all descendant monitor model elements.
You can then edit the fields that are currently read-only because they are managed by the application, but you will no longer be able to synchronize the monitor model with the application.
To add more templates to the monitoring context, click Add on the table and select the templates to add.
To remove a template, click Remove. You are given the option of removing all the monitor elements that are managed by the template (assuming they are not required for the implementation of any other templates) or just removing all associations to the referenced monitor model elements from the template and removing it from the list of applied templates.
What to do next
You can add keys, inbound events, triggers, metrics, counters, stopwatches, outbound events, and nested (or child) monitoring contexts to this monitoring context. To add one of these elements, right-click the monitoring context in the model tree, click New, and select the element to add.To filter the elements that are visible in the model tree, right-click a node and click Filter. Select any elements that you do not want displayed.