IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing monitor models > Create monitor models > Defining monitor details models

Defining inbound events for monitoring contexts

You define an inbound event to specify that you want this monitoring context to subscribe to a particular event.

To define an inbound event:

Procedure

1. Click the Monitor Details Model tab of the editor, right-click the monitoring context (or any element of the monitoring context) in the model tree, and click New > Inbound Event.

2. In the Create New Inbound Event window, type a name and click OK. The name is limited to 256 characters. As you type the name, a default ID is created for you, although you can change it if you prefer. The ID is required and must be unique within the monitoring context. 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 inbound event is added to the model tree under the monitoring context, and the form editor opens so that you can define the event.

3. 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.

4. If the event definition is in a Common Base Event file, specify an extension name. Click Browse and navigate to the file. The file must have been previously imported into the project or must be in an associated project. You can specify both an extension name and event parts if the event definition contains information from both types of structure. An import statement referencing the Common Base Event file is added to the XML source document, which is reflected in the table on the Event Model page. This table displays the import location for each event definition file used in the monitor model.

5. If the event definition (or part of the event definition) is in an XML Schema Definition (XSD) file, click Add to add a new event part to the Event parts table. Using the detailed information in Defining event parts, define all event parts required for the inbound event.

6. To restrict the events that are received by this monitoring context, add a Boolean expression in the Filter Condition box. The Boolean expression can reference attributes that are defined in the inbound event type. If the filter condition evaluates to true, the correlation expression is evaluated. The default value is a blank, which always evaluates to true.

   If you press Ctrl+Space for content assist, a small window is displayed to help you write the expression. In this window, you can select valid operators, functions, and attributes from the inbound event.

7. To identify the monitoring context instance or instances that receive this event at run time, add an expression in the Correlation Expression box. After an event has passed the filter, the correlation expression is evaluated once for each instance of the monitoring context that currently exists. This evaluation might result in zero, one, or multiple matching instances. For each case, the settings of the inbound event definition determine which action to take: create a new instance, deliver the event, ignore the event, treat as an error, or try again. The default value for the correlation expression is a blank, which always evaluates to true.

   If you press Ctrl+Space for content assist, a small window is displayed to help you write the expression. In this window, you can select valid operators, functions, and the following elements within your model:

   • Inbound event attributes
   • Keys, metrics, counters, and stopwatches in the same or a higher-level monitoring context

   Often you will want to create a correlation expression that compares an attribute of the inbound event to the key of the monitoring context.

8. Specify the actions to take if no matching monitoring context instances are found, one instance is found, or multiple instances are found. If one monitoring context instance is found, you can ignore the event, treat it as an error, or deliver the inbound event to the instance. If multiple monitoring context instances are found, you can ignore the event, treat it as an error, or deliver the inbound event to any one, or all, of the matching instances. If no matching monitoring context instances are found, you can choose to ignore the event, treat it as an error, or create a new monitoring context instance to receive the event.

9. Specify a value in the Parent correlation field to specify the parent of this inbound event.

   This value indicates the field or fields in the event that determine which instance of the parent monitoring context is associated with this monitoring context. The value is required if the monitoring context is not a root monitoring context.

10. 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 a quality of service property at the inbound event level, you can override any properties specified at the monitoring context level. Select Override inherited value from parent context and edit the value of the corresponding field.

    1. 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.

    2. 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.

    3. 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 you press Ctrl+Space for content assist, a small window is displayed to help you select the event attribute from the inbound event.

11. Optionally specify the event partition path by selecting the check box and typing a value.

    The event partition path indicates the field in the inbound event that represents the root monitoring context instance. If you do not specify a value, the event partition path is derived from a correlation expression.

    If you choose to have the event partition path calculated, make sure that you specify a value in the Correlation expression or Parent Correlation Expression field.

• Defining event parts
  An event part is an XML Schema Definition (XSD) type that provides information about the structure of part of an event. A single event definition can have different event parts that are defined by different XML schemas. Each event part describes how to identify and locate itself within the actual event received at run time.
• Handling duplicate events
  Sometimes monitor models receive duplicate events.

  For example, if a client application that is sending events to the monitor model through the REST event emitter does not receive its expected response from the emitter, it might decide to send the event a second time. Depending on the effects of an incoming event, the monitor model might need a way to recognize and handle a duplicate arrival. If the event only sets metrics by copying some of its content, setting the metrics twice will cause no harm. However, if counters are incremented or outbound events are triggered by the event, duplicate deliveries are undesirable.

Defining monitor details models