Criteria Parameter Structure

Predefined Content Guide › Business Logic Modules › Generic Business Logic Modules › Success Calculations Module › Criteria Parameter Structure

Criteria Parameter Structure

There are two parameters that define criteria in the Success Calculations module: the filter criteria and the success criteria. The structure of these parameters is identical.

The function is called with the current event details (i.e. the eventDetails parameter from the event handler) so as to base the success test on the details of the event being handled. This table parameter includes all the information needed to decide whether the current event is to be considered a success or not.

The return value is either true or false, based on the calculated result.

No entries in this table mean that all entries are considered successful.

The success criteria is calculated based on a comparison of a single or multiple fields to specific values, or based on the evaluation of expressions. Multiple criteria lines are joined based on user defined logical relations.

For example, if a successful event is defined as one that has a value in the field result that is between 3 and 6, the user would supply two lines, using the and relationship, and ask for:

result > 3 and result < 6

The format of the table is as follows:

Row #	Argument 1	Operator	Argument 2	Inter-row logical link
1
2
…

The table fields are:

Argument 1 – This field should be filled with the name of a field in the event details from which a value is to be extracted. When the Eval operator is used, this field is ignored, and may be left empty. This field can also contain the following:
- @Resource – This returns the name of the event’s resource (eventDetails.Resource).
- @EventType – This returns the event’s event type (eventDetails.EventType).
- @SenderMetric – This returns the details of the metric which sent the event reusability event being handled (eventDetails.Sender).
Operator – This field should be filled with the operator with which to compare arguments 1 and 2. This field may be one of the following values:
- <
- >
- <=
- >=
- <> (not equal)
- Eval
When any of the normal comparators are used, the system takes the content of the field specified in argument 1, and compares it to the value in argument 2, using the selected comparator.

If the Eval comparator is specified, the argument1 field is ignored. Instead, the content of argument 2 is taken and evaluated directly as an expression.
Argument 2 – This field should be filled with the value to be compared to the content of the field specified in Argument 1. For example, if any value greater than 5 in the field result is considered a success, the string result is placed in argument 1, > in the operator field and the value 5 in the argument 2 field.
When Eval is specified in the operator field, this field must contain an expression. An expression is a term in Visual Basic that can be evaluated as to whether it is true or false. For example, and evaluation term can be used to compare the results field to the value 5, as done above, by specifying the following term (all of it goes in Argument 2):
```
eventDetails("result") > 5
```
In this example, the term being evaluated is a comparison between the content of the result field and the value 5. Of course much more complex terms can be evaluated as well. A more complex example is the following term:
```
Tools.NetTime(eventDetails("startDate"),eventDetails("endDate")) > eventDetails("MaxTimeSpan")
```
In this example, the term is a comparison of the result of the net time method in the tools object, based in the values from two fields, compared to the value taken from a third field.
Inter-row logical link – This field should be filled with the logical relationship between the comparison of the current line and that of the next one. The user can implement multiple comparisons. Each comparison or evaluation term is placed in a separate line in the table. This field defines how the results of the comparison relate to each other. Comparison relationships do not follow normal logical priority rules. Instead, they are always evaluated in the order they appear in the table. Legal values for this field are only and, or. When the table contains only one line, this field is ignored and may be left empty.

Success Calculation Module Interface

The following table lists the parameters.

Name	Description
IgnoreTimeslots	(optional, string [True/False]) - whether to handle events that occur outside of timeslot.
Debug	(optional, string [True/False]) - whether to print debugging comments to the log.
AggregationType	(optional, string [SUCCESSCOUNT,PERCENTOFSUCCESS]) - Whether to calculate the percent of success or the count of successful entries.
SuccessCriteria	(mandatory, table)- How to determine if an event is to be considered a success or a failure
FilteringCriteria	(optional, table) - How to determine if an event is to be handled or filtered out.
EventIdFieldName	(optional, string) - The name of the field to us as an event identifier for repeat event recognition.

Module Dependencies

The following table lists the included modules.

Name	Description
Log Library (LL)	Library for enhanced logging functionality.
Parameters Kernel Library (PKL)	Library responsible for verifying and populating module parameters.
Aggregation Library (AL)	Library used to produce results for common calculations.
Callback Kernel Library (CKL)	Library that enables the callback functionality.
Parameters Overlay - Basic Actions Library (POBAL)	Library that contains specific parameter loading functions and calls the parameters kernel library for the actual loading of the information.
Distinct Entity Library (DEL)	Library responsible for telling the caller whether a specified entity has already been seen.
Filtering Criteria Evaluation Library (FCEL)	Library responsible for filtering events according to user specifications.
Success Criteria Evaluation Library (SCEL)	Library responsible for the decision as to whether the current event is to be considered a success or a failure.