You can create two types of objects to monitor events that are captured from a client framework and passed as messages to Tealeaf.

• Step attributes are hit attributes that acquire its data from a step. Step attributes are specified in a slightly different manner but complete an identical function.
• Step-based events are standard events that are configured to fire on one of the steps triggers. As conditions, they can use any standard type of Tealeaf condition, and also step attributes.

Step trigger types

To support step-based eventing, the Event Manager provides two trigger types:

• Every Step: Event is evaluated with other events in each step.
• After Every Step: Event is evaluated after every step is evaluated.

  Note: This trigger is rarely used.

In the previous example, any event triggered to fire on Every Step is checked for each combination of JSON message and environmental data. In the previous example, any Every Step event is checked for the load, unload, exception, and other data message.

Note: Step attributes are permitted to reference objects from the parent hit. As a result, you can reference hit attributes in step events, but not vice versa.

In the event definition, the trigger can be selected from the Evaluate drop-down:

Available triggers are displayed in the order of evaluation. For a particular hit with underlying steps, each Every Hit event is evaluated first, followed by each Every Step event and After Every Step event. Then, the After Every Hit events are evaluated.

Note: The events that fire on each trigger determine the availability of data. An event can use data from any event that fired before the current event. In a multi-hit session, the After Every Hit trigger fire on the previous hit before the events configured to fire on Every Hit from the next hit. The same applies to step-based triggers.

The order of firing is more accurately displayed as a nested structure:

* First Hit of Session
    * Every Hit
        * Every Step
        * After Every Step
    * After Every Hit
    * Last Hit
* End of Session

Considerations for using the After Every Step trigger

In almost all cases, when you create step attributes, you are interested in the current context of the session. You create attributes to monitor the current data that is available as of the current step. As a result, the After Every Step trigger is rarely used.

In the example below, the After Every Step trigger is used. This scenario mirrors the After Every Hit trigger usage, except that it applies to steps instead of hits.

The After Every Step trigger is useful when you must compare the current state with the previous state. For example, suppose you want to know whether users clicked the same object twice in a row.

• To test this scenario, you must know both the object currently being click, and the previously clicked object. If the events that track both the current and previous states fire on the same trigger, they are updated at the same time and therefore always have the same value.
• However, if the previous state event fires just after the current state value by using the After Every Step trigger, the previous state event is not updated when the current state event fires. Therefore, you can compare the current state with the previous state by using an event that fires on the Every Step trigger.

Note: Form messages contain the currState and prevState properties within a step. The currState property refers to the final value of the form field after editing, and prevState refers to the default value before editing. These references do not work for testing if the same action occurred twice, since the default value can be reset to blank each time it is accessed.

Privacy

To manage blocking or masking of sensitive data, Tealeaf provides privacy mechanisms to manage specific data before it is transmitted to Tealeaf.

Important: Application of privacy blocking or masking in the PCA or in the Windows™ pipeline requires complex regular expressions, which can cause significant performance degradation if improperly specified. Use the privacy solution that is provided with your client framework to manage sensitive data.

Indexed and step-based events

Step-based event data is not indexed by default. You can, however, search for events through BBR and RTV.

It is possible to move data from one location in the request into another section which is automatically indexed for search.

Note: If you must index some JSON-based session data for search, you must use a privacy rule to insert the data into the [appdata] section. Creation of the rule requires configuration of a regular expression to locate the data. Regular expressions are considered an advanced configuration option, as if they are poorly specified, they can significantly impact system performance.