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

Defining outbound events for monitoring contexts

You can define an outbound event that will be sent from this monitoring context. Outbound events with an extended data element named BusinessSituationName can be received by the Monitor action services, which allows an administrator to specify the actions to take in response to an event.

To define an outbound 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 > Outbound Event.

  2. In the Create New Outbound Event window, type a name in the Name field and click OK. You might choose a name describing the reason for the event, such as Threshold Exceeded or Unacceptable Response Time. 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.

  3. If you want the outbound event to be received by the action services in Business Monitor (for sending notifications), click Configure this event to be processed by IBM Business Monitor action services. You are prompted to select or create the trigger that causes the outbound event to fire. The outbound event is associated with the trigger and is assigned the event type (that is, the extension name) of ActionServicesEvent. The BusinessSituationName attribute of the outbound event is set to the name of the outbound event.

    The outbound event is added to the model tree under the monitoring context, and the form editor opens so that you can define the event.

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

  5. 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. (If you clicked Configure this event to be processed by IBM Business Monitor action services, the ActionServicesEvent extension name was already added for you.) 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.

  6. 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 the event part. Typically there will be only one event part for an outbound event. If you are defining events using XML schemas, it is easiest to define a global element in the schema and then set the type attribute of the event part to point to that global element.

  7. If you clicked Configure this event to be processed by IBM Business Monitor action services, then in the Outbound Event Content table, specify the value for the BusinessSituationName attribute. By default, the value is set to the name of the outbound event.

  8. In the Outbound Event Content table, click Add or double-click a row to add a new trigger to the table. The triggers specify when the outbound event is sent, and you specify the value for each attribute. If you do not add any expressions, the outbound event will have no content at run time. You might want to add different triggers to cause different values to be sent. For each row, complete these steps:

    1. For Common Base Event events such as ActionServicesEvent, the first column shows the names of the attributes for the outbound event type, under Property Data and Extended Data. Only the values that you can set are shown; the inherited attributes are not included. The types of the attributes are displayed in the second column. If this outbound event is to be received by the Monitor action services, it must contain an extended data attribute of type string named BusinessSituationName and you must enter a value for that attribute (for example, some text describing the situation that caused the outbound event to be sent).

      For event parts, the first column shows the event part name and the second column shows the type associated with the event part.

      • Elements with a multiplicity greater than zero are shown as arrays in the table. Arrays have a parent element that shows the array type and can be selected to add individual array members. Right-click the parent array element and click Add Elements to specify the number of array elements to add. By default, new array elements are of the same type as the parent array element and are shown in the tree with the integer array index.

      • You can specify that you want any node in an event part tree to use a derived type instead of the original type assigned to that element.

        For example, if an XML schema complex type defines that a given element is of type A, you can choose to override that setting to indicate that type B will be used instead, where B is defined as an extension of A. Derived types can also be used for individual array elements. It is not necessary that all array elements be of the same type; each element can be assigned to be a different derived type.

        You can also specify derived types at the parent array element level, in which case all elements in the array are designated as the same derived type. Right-click the node and select Use Derived Type. The New Event Part window opens with the path specified and read-only, and you can create a new event part, which is also added to the Event parts table.

        When you choose to use a derived type, an event part is created that associates the new type with the path expression that points to the location in the outbound event where the derived event definition structure applies. So, if you choose to use a derived type for an array element, an event part will be created in the Event parts table with a path that points to that individual array element. Because all event parts are also shown as elements beneath the root trigger element, the same content will be located in two places when derived types are used. If you enter an attribute value expression in the first column in one location, it will automatically be displayed in the first column in the duplicate location as well.

      • You can enter a type value for an xs:anyType slot. Right-click the anyType element and click Set Type. The New Event Part window opens with the path specified and read-only, and you can create a new event part, which is also added to the Event parts table.

    2. Click the Expression cell for each attribute and add an expression. You can either type directly into the cell, or, for a large expression, click the button that is displayed to open a resizable window. The content of each attribute can be set based on the trigger.

      For example, if this outbound event is sent when a bill payment is late, the outbound event attributes could contain the ID of the late order, the bill payment due date, and the customer information. 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:

      • Metrics, counters, and stopwatches in the same or a higher-level monitoring context.
      • Metrics, counters, and stopwatches in child contexts and down, but only if the expression is evaluated because of a trigger firing in the child context.

      • Inbound event attributes, if the outbound event is triggered by that inbound event.

      Refer to "Expression support" for supported expressions, and refer to your event schema definition for a list of valid attributes.

  9. To restrict the conditions under which the outbound event is emitted, add a Boolean expression in the Filter Condition box. If the filter condition evaluates to true, the event is emitted. 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 the following elements within your model:

    • Attributes in the outbound event to be emitted.
    • Metrics, counters, and stopwatches in the same or a higher-level monitoring context.
    • Metrics, counters, and stopwatches in child contexts and down, but only if the expression is evaluated because of a trigger firing in the child context.

    • Inbound event attributes, if the outbound event is triggered by that inbound event.

    See "Expression support" for supported expressions.

Defining monitor details models