Integrated into the Event Manager, the Event Tester enables you to test active events and hit attributes, even if they are saved in draft mode, against sessions that you upload to the server. This integrated tool provides a quick method for validating the event objects you define before you deploy them into the live transaction stream.

The Event Tester enables you to verify functionality of events and hit attributes before deployment in the capture stream and to resolve issues when these objects are failing or exhibiting unexpected behavior.

Note: Before you save events or hit attributes to the server, you should get in the habit of testing them in the Event Tester. As soon as active events are saved to the server, they are immediately applied to subsequent hits processed in the pipeline.

The Event Tester provides insight into the following data:

• Events: You can select specific events to test and then review the hits of the selected session where they successfully fired. As part of the displayed results data, you can review the recorded event values and any values that are recorded for dimensions that are associated with the event.

  A common issue with event definition is that the recorded value is not the expected value. Since events can be configured to record the first or last value that is detected in the session, you can use the Event Tester to determine if you are using the appropriate value.

• Hit Attributes: In many cases, hit attributes are used as conditions for events, so the Event Tester can be helpful in isolating issues occurring with hit attribute definition. Through the Event Tester, you may select the specific hit attributes to verify in the test and then review the captured values for the hit attributes in the hits of the selected session.

  Because hit attributes are evaluated on each hit of a session, the Event Tester may reveal that the attribute is firing much more frequently than expected or wanted. By narrowing the definition of the hit attribute, you can retest it against the selected session to limit the firings to the wanted hits and to the wanted number of occurrences on each hit.

To use the Event Tester, complete the following steps.

1. Select or load a session as test data.
2. Run the test. All active events are tested against the selected session.
3. Select events or hit attributes or both whose results you want to view.
   • When you select an event, any hit attribute that is referenced in the event is automatically selected and displayed in the Hit Attributes tab. You can modify these selections as needed in the other tab.
   • If you recently created a step-based event, it may take a few minutes before it is available for selection in the Event Tester.
   • If you create hit attributes from the request buffer, note that the [HitType] section and [TLFID_*] sections (where * is the identifier for the fact) are generated by the event engine and cannot be detected in live sessions.

     As a result, any events using these hit attributes do not fire in the Windows™ pipeline and are therefore not available for searching. They do fire, however, when they are evaluated in the Event Tester on sessions that were already passed through the Canister.

4. After you selected a session and the events and/or hit attributes to test in it, the results are available for review.

If you try to test a specific event on your web application, you might find it easiest to create the session using a unique means of identifying the event. For example, you might know that a form field value is tracked as a searchable event by Tealeaf. Go to your web application, enter a value in this tracked field, and then complete the activity that triggers the event you are testing. You can then send the session to the Event tester through the session list.

You can view the results that are based on these options:

• Event/Hit Attribute - Results are displayed by the event or hit attribute name. Hit and URL information is available when you expand a specific event or hit attribute.
• Hit/URL - Results are displayed by the hit number and URL of the hit on which events or hit attributes occurred. Event and hit attribute information is available when you expand a specific hit/URL node.
• By default, the Event Tester displays all events and hit attributes that were selected for inclusion and that occurred in the session. To hide objects that registered zero counts in the session, clear the Include Zero-Count Items check box.
• By default, the Event Tester displays only the occurrences for which values are recorded. To expand the display to all occurrences of events that occurred in the session, clear the Limit Event Results to Tracked Occurrence check box.

Numeric values in the Event Tester are displayed as the strings were recorded by the Canister. Display formatting, including localized decimal and currency indicators, is not applied.

When a session discard event is detected in the Canister, the session is marked for discarding, and no subsequent events in the session are evaluated. In the Event Tester, however, sessions are not discarded, so events that occur in a session after a session discard event are reported in the Event Tester.

When you display the results by Event/Hit Attribute, the following general structure is applied:

+ Events
  + CountOfOccurrences - EventLabel1
    + CountOfOccurrences - Event1
      + HitNumber1 - URL1
        + ReportGroup1Name (if defined)
          + Dimension1Name
            + Value: Dimension1Value
          + Dimension2Name (if defined)
            + Value: Dimension2Value
        + ReportGroup2Name
      + HitNumber2 - URL2
    + CountOfOccurrences - Event2
  + CountOfOccurrences - EventLabel2
+ Hit Attributes
  + CountOfOccurrences - HitAttributeLabel1
    + CountOfOccurrences - HitAttribute1
      + HitNumber1 - URL1
        + Match Count: NumberOfMatchesInHit
        + Match Value 1: MatchValueForMatch1
        + Match Value 2: MatchValueForMatch2 (if present)
      + HitNumber2 - URL2
    + CountOfOccurrences - HitAttribute2
  + CountOfOccurrences - HitAttributeLabel2

When you display the results by Hit/URL Attribute, the following general structure is applied:

Note: These results are not displayed by page. For example, in BBR you can display session data by page. In the Event Tester, the results are displayed by the hit on which they occurred, which may be different.

+ EventCount1 - HitAttributeCount1 HitNumber1 - URL1
  + Events
    + EventDisplayName1
        + ReportGroup1Name (if defined)
          + Dimension1Name
            + Value: Dimension1Value
          + Dimension2Name (if defined)
            + Value: Dimension2Value
        + ReportGroup2Name
    + EventDisplayName2
  + Hit Attributes
    + HitAttribute1
      + Match Count: NumberOfMatchesInHit
      + Match Value 1: MatchValueForMatch1
      + Match Value 2: MatchValueForMatch2 (if present)
    + HitAttribute2
+ EventCount2 - HitAttributeCount2 HitNumber2 - URL2

Depending on the results, you may want to do one of the following:

• Retest with a different session.
• Change events that are displayed in the test. The test does not need to be rerun.
• Change hit attributes that are displayed in the test. The test does not need to be rerun.
• Modify event or hit attribute definitions.

Methods of providing sessions to the Event Tester

There are two methods of providing a session to the Event Tester: from the Selected Session tab and from a .TLA file.

• From Selected Session - When you run a search from the Portal, you can send the session to the Event Tester through the session list.

  Note: The sessions that you send to the Event Tester are removed when you log out of the Portal. If you wish to retain a session for testing purposes, you should load it from the Session List into RTV and save it as a .TLA file. You can then upload that file to the server, where it is retained until someone removes it.

  • You can send multiple sessions to the Event Tester from the session list.
  • By default, the internal session ID is assigned as the session name. If needed, you can rename it for easier tracking in the Event Tester.
• From TLA file - You can save a .TLA file from RTV to your local desktop and then upload it through the Event Tester.

  Note: Sessions that are saved as .TLA files through RTV might have a different set of events and hits if RTV merged session fragments. To ensure consistency of results, you should verify that any auto-merging options are disabled in RTV prior to saving the .TLA file.
  The Event Tester does not merge session fragments. Only the segment that is submitted to the Event Tester is available.

Sessions that are loaded or sent to the Event Tester are displayed in the Select Session tab.

Sessions are stored as standard Canister session data files or as archive (.TLA) files.

Note: If the .TLA archive contains multiple sessions, only the first session in the archive is tested.

In the Session tab, you select or upload the session containing event and hit attribute data for your test or replay available sessions for further verification.

Note: You can only replay sessions that you have sent to the Event Tester from the Portal. You cannot replay .TLA files, as they are not available for Browser-Based Replay. .TLA files may be downloaded and replayed through RTV.

Uploaded files are stored in the following directory on the server:

<install_directory>\System\EventTest

Tips on selecting sessions: For Event Tester performance, choose an example session that contains the fewest number of pages in which the test condition is expressed. The number of events that fire in a test session does not affect the performance of the Event Tester. However, a high number of tested events can affect performance of the Event Manager user interface.

If the Event Tester encounters an Out of Memory error, this condition most likely also occurs when the events and hits attributes are used to process hits on the Processing Server. In this situation, the events and hit attributes definitions should be modified to use fewer resources. For example, a hit attribute that is defined to find the pattern <br> in an HTML response may cause excessive memory usage to store all occurrences of the pattern in the data. It is best to redefine it to isolate the hit attribute to the wanted instance.

Download Event Tester logs

Tealeaf administrators can download Event Tester logs through the Portal.

1. In the Portal menu, navigate to Portal Management.
2. In the left panel, click the Logs category.
3. Click Logs and Configuration Files.
4. Select Canister Application Servers.
5. Make other selections and configuration choices as needed.
6. Click Download.

   The Canister files, including the Event Tester log files, are downloaded to the location you specify.