About Conditions

You can associate one or more conditions with a transaction. A condition is an expression that Business Transaction Management evaluates against a transaction instance. You might use conditions to have Business Transaction Management let you know about the following kinds of events:

  • An order larger than $10,000 is processed.

  • A customer's fault rate is greater than 1%.

  • A transaction instance has exceeded its expected completion time.

You can define three types of conditions for a transaction:

  • Content-based conditions, which issue an alert when the criteria you specify is met. The criteria might specify a property value and/or a fault for a particular operation.

  • Missing message conditions, which issue an alert if the message you specify is not seen by the system in the specified time period.

  • Fault monitoring conditions, which issue an alert when a fault occurs on any operation in a transaction. These type of conditions are the equivalent of defining a content-based condition for any fault on any operation in your transaction. Fault monitoring conditions are disabled by default.

When a condition evaluates to true, Business Transaction Management does the following:

  • Creates a condition alert based on the severity specified in the condition definition

  • Tracks the number of occurrences of the condition

  • Assembles and logs the instance of the transaction that evaluated to 'true'.

  • Keeps the logged transaction instance for the length of time specified for the transaction's "Retain archived condition instances" value in the Storage Settings tab. By default, this is 30 days.

Conditions are evaluated on a per-instance basis; therefore, instance logging must be enabled. If you define a condition for a transaction and you have not enabled instance logging, Business Transaction Management automatically turns it on for that transaction.

When you define a condition, you also assign a severity level to the alert that will be issued when the condition evaluates to true. Severity levels include info, warning, and failure.

Working with Conditions explains how you define conditions, view condition information, modify a condition, and delete a condition.

Defining and Evaluating Conditions

You must observe the following limitations when defining content-based conditions.

  • Condition definitions can include multiple clauses, but all clauses must reference the same message (operation.request, operation.reply or operation.fault).

  • A content-based condition can test for a property value, a fault value, or both. If both, the property must be defined on the fault phase of the operation.

  • Only message elements that are referenced by means of properties can be used in a condition definition, with the exception of fault codes.

The system evaluates a content-based condition when the message for which it is defined is seen. If the condition evaluates to true, Business Transaction Management will correlate back to the transaction's start message to make sure that the instance that has satisfied the condition has been called from within the transaction. If so, the resulting instance is assembled and saved for the time duration specified on the transaction's storage settings Retain archived condition instances.

The system begins to evaluate a missing-message condition when it sees the starting message for the transaction. It then looks for the message for the period specified in the condition definition. If it does not see the message in that period, the missing message condition evaluates to true.

Once you have defined a condition on a transaction, it is listed in the transaction's Conditions tab.

Interpreting Condition Alerts

Alerts are commonly thought to signal that something bad has happened, for example, that an error has occurred. However Business Transaction Management uses condition alerts to signal the occurrence of any kind of message pattern. So, depending on the condition definition, an alert could signal a positive event: a customer has doubled an order, a process has attained a certain level of efficiency, sales in a particular region have exceeded the norm, and so on. You can use severity settings to signal whether the alert denote a positive event (info level) or a negative one (warning or failure level).

Once an alert is issued, you have several ways to deal with the situation. You can:

  • view the logged instance

  • notify interested parties by email

Condition alerts that have occurred can be queried, filtered, and viewed on the Alerts tab of the related transaction instance. Alerts created in the last 24 hours for all objects can also be filtered and viewed using the Condition Alerts view (from the Navigator bar). The dashboards also include various alert counts.